The present invention generally relates to an object oriented system platform for a telecommunication system that provides subscriber services. Such a platform can generally be described as including an operating system in a lower layer, an application platform located thereon and containing suitable telecommunication abstractions in the form of resource objects, and thereupon an upper layer containing desired applications in the form of base and supplementary functions providing base and supplementary services.
Subscriber services provided by a communication system can include base services and supplementary services which are provided by base functions and supplementary functions, respectively of the system. The supplementary functions of a system are optional, market dependent and can be supplied to a customer after the system providing the base services has been supplied. The later is often the case for subscriber services such as Call Waiting and Call Forwarding on Busy.
Supplementary services are often introduced when a system providing the base service has already been developed and supplied. The traditional way of updating the system is then to edit and recompile the existing implementation for having it to support also the new supplementary function and have it to take care of the coordinations between the new and the existing extension functions.
In U.S. Pat. Nos. 5,057,996 and 5,136,712 there is described an object oriented operating system including hardware layers, layers with operating system functions, and software layers. Access to specific objects is required for use of corresponding resources in the system. The objects have a consistent data structure and a consistent method for defining the operations for each object type. The system admits routines for generating new object types without modifying the core of the operating system.
In U.S. Pat. No. 5,421,015 there is described an object oriented data processing system comprising an extendable set of object types and a corresponding set of object managers.
A general main object of the invention is to render more efficient, in a communication system, the management of the supplementary functions of a system, i.e. the parts of the system that are optional, market dependent or are supplied to a customer after the system providing the base services has been supplied.
A more determined object is to attain this efficiency by enabling modification and extension of the services provided by a system without needing to change the software of the functions that have already been implemented and supplied.
These and other objects which will appear henceforth, have been attained by the characterizing features stated in the patent claims.
In a system platform of the kind defined by way of introduction, the upper layer is implemented with base objects and extension objects. The base objects are object types that implement, with one or more methods included therein, base functions that may need to be extended in the future, and the extension objects are object types that, with one or more methods included therein, enable implementation of extension functions being extensions to the base functions. Each base object type is designed for a particular task, that can be performed with a minimum of coordination with other base objects. The extension objects are designed to admit addition of new services and modification and extension of existing services without changing the software of the services that have already been implemented and supplied. The extension objects can also include object types implementing extension functions which form extensions to the extension functions, and also object types implementing interaction handling extension functions, which handle interaction between supplementary services.
The extension objects enable introduction of extensions in a system in operation which are dynamically bound to base objects that shall be modified.
The extensions are configurable, i.e. enable adding and removing modifications of the system in runtime in a generic way without the designer himself needing to design code for the activation/deactivation proper of the extension, that is handled by the platform.
The behaviour of included object types is defined by describing the behaviour of each method therein as a finite state machine. This state machine consists of a finite number of states and transitions between these states where the code defining the method is executed. The extensions are added at the states, where they then take over the execution control and returns it after having finished its own execution, to another or the same extension point.
The base and extension object types support an extension concept that allows modification and extension of the system without it being necessary to change the existing implementation of the system. More particularly this is attained by loading only definitions of the extensions in the system, that indirectly modify the behaviour of the system by taking over the execution control in specific predetermined extension points.
A specification for an extension object defines at which extension points in the extension object the extension is assumed to take over the control and at which extension points it can return the control.
When an extension object takes over the control, a predefined extension method starts execution.
A runtime system handles creation of extension objects and invocation of their extension methods at the stated extension points.
An extension object has access to attributes and methods of the base object or the extension object from which the extension takes over the control. The attributes and methods may only comprise such that is declared in an object type specification that can be accessed.
In the object type specification there are defined also access restrictions for each extension point by defining that only a specific subset of the attributes and methods in the specification are available for extensions taking over the control in a certain extension point.
The object type specification for an extendable object works like an interface that delimits the amount of information that is visible and available to extensions of the extendable object. An interface layer that is used together with the extension concept is defined by extension views which each define a subset of information in the specification of an extendable object that shall be able to be accessed by the extensions using the view.
For a base object there is a specification that, on the one hand, works as an interface description showing states, attributes and methods available to the extensions and, on the other hand, defines an interface towards the client object that needs to create instances of the base object. The interface is defined by methods of the base object type, that decide which parameters that can be used when creating the new instance.
The specification provides a high level description of the behaviour of the base object type while leaving out implementation details which are unnecessary for attaining an understanding of the function of the object type.
An abstraction layer that is created by an underlying object logic that is used by the base object, and local methods in the base object comprising use of the object logic, contribute to the high abstraction level.
A reasonable abstraction level in a specification is obtained by showing the wait state of the base object in the specification and possibly some selected non-wait states which are fundamental for understanding the function of the base object. Code for execution between the shown states is introduced in local methods declared, but not necessarily behaviour specified, in the specification. A judgement of that to be shown in the specification includes considering which parts of the object type that may be exposed to extensions in the future.
All states, both wait states and non-wait states and all explicitly denominated extension points, are shown in the method specification. Action code is used at state transitions in local methods. If certain parts of the behaviour do not need to be extendable, these are introduced in their entirety in local methods being defined in the specification or realization, or on an implementation level.
The object type realization is used for parts of base objects which do not need to, or cannot, be extendable, and which are not necessary to be shown in the specification to create a high level description, but where a definition is preferred instead of using implementation language directly. In the realization there are introduced definitions of local methods that introduce action code. In the realization there is provided, while overriding behaviour definitions included in the specification, a more detailed behaviour definition, that implies a refining of the behaviour specification that is provided in the specification.
The extension concept according to the invention has a number of valuable properties. It is a fine-grained way of making modifications, by it being not necessary to override whole methods, which is the mechanism that is available in most object oriented formalisms. Instead the override can be performed in certain extension points within methods. The extension concept forms a frame work for taking care of the complexity caused by introducing many supplementary functions in a ready-developed and supplied system. This is made possible by describing the modifications caused by each extension separately, whereupon the extensions can in turn be coordinated when there is a need. Such coordinations between supplementary functions can also be expressed as separate extensions, in this case as extensions to the supplementary functions. This makes it possible to manage the optional parts of the system and their dependencies in a modular way.